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Method of announcing sessions 



Description 

The present invention relates to a method of announcing sessions particularly, 
although not exclusively to a method of announcing multimedia service sessions 
through a multicast network. 

Audio, video and other types of data may be transmitted through a variety of types 
of network according to many different protocols. For example, data can be 
transmitted through a collection of networks usually referred to as the "Internet" 
using protocols of the Internet protocol suite, such as Internet Protocol (IP) and 
User Datagram Protocol (UDP). 

Data is often transmitted through the Internet addressed to a single user. However, 
it can be addressed to a group of users. This is known as "multicasting". 

One way of multicasting data is to use an IP datacasting network, similar to a 
terrestrial digital video broadcasting (DVB-T) network. Through such an IP-based 
broadcasting network, one or more service providers can supply different types of 
IP services including on-line newspapers, radio, television and download of music 
songs, videos, pictures and software. These IP services are organised into sessions, 
each session comprising one or more media streams in the form of audio, video 
and/or other types of data. 

To determine when and where these sessions occur, users refer to an electronic 
service guide (ESG), similar to an electronic program guide (EPG) used in DVB. 
The electronic service guide is usually divided up into parts and transmitted to 
users. 

This approach, however, has several drawbacks. On the one hand, if any sessions 
are updated, then the user usually has to wait until a new version of the service 
guide has been received before they receive notification of updated sessions. On 
the other hand, few sessions are usually updated. Therefore, much of the data 
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received by the user is superfluous. This is wasteful both in terms of processing 
power and electrical power, both of which tend to be in short supply in battery- 
powered mobile terminals. 

5 The present invention seeks to provide an improved method of announcing sessions 
transmitted through a network. 

According to a first aspect of the present invention there is provided a method of 
announcing sessions transmitted through a network, the method comprising 
10 providing a first set of announcements describing a plurality of sessions and 

providing a second set of. announcements describing at least one updated session. 

This has the advantage that it is possible to choose whether to be provided with the 
first set of announcements describing the plurality of sessions or to be provided 
15 with the second set of announcements describing any updated sessions. This allows 
updated sessions to be announced more quickly and efficiently. 

An updated session may be a new session which is added to the plurality of 
sessions, a one of the plurality of sessions in which content is added, changed or 
20 delete or a session which is deleted from the plurality of sessions. 

Providing the first set of announcements and providing the second set of 
announcements may comprises providing the first set of announcements through a 
first channel and providing the second set of announcements through a second, 
25 different channel. 

Providing the first set of announcements and providing the second set of 
announcements may comprise providing the first set of announcements through a 
first address, preferably a destination address, such as a first multicast IP address, 
30 and providing the second set of announcements through a second, different 

address, preferably a destination, address, for example a second, different multicast 
IP address, respectively. 
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Providing the first set of announcements and providing the second set of 
announcements may comprise providing the first set of announcements through a 
first port number and providing the second set of announcements through a 
second, different port number respectively. 

Providing the first set of announcements and providing the second set of 
announcements may comprise providing the first set of announcements through a 
first logical channel and providing the second set of announcements through a 
second, different logical channel respectively. 

Providing the first set of announcements and providing the second set of 
announcements may comprise including in each announcement of the first set of 
announcements data for identifying the announcement as an announcement which 
describes a one of the plurality of sessions and in each announcement of the second 
set of announcements data for identifying the announcement as an announcement 
which describes a one of the at least one updated session. 

Providing the first set of announcements and providing the second set of 
announcements may comprise including in each announcement of the first set of 
announcements respective data for specifying a position of a corresponding session 
within a first portion of a session directory and including in each announcement of 
the second set of announcements respective data for specifying a position of a 
corresponding session within a second portion of the session directory. 

25 Providing the first set of announcements and providing the second set of 

announcements may comprise providing the first set of announcements through a 
first physical channel and providing the second set of announcements through a 
second, different physical channel respectively. 

30 Providing the first set of announcements and providing the second set' of 

announcements may comprise providing the first set of announcements through a 
first network and providing the second set. of announcements through a second, 
different network respectively. 



20 
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The method may further comprise providing a third set of announcements 
describing another plurality of sessions including the at least one updated session. 

5 The method may comprise providing the first set of announcements through a first 
channel, providing the second set of announcements describing at least one updated 
session through a second, different channel and providing a third set of 
announcements describing another plurality of sessions including the at least one 
updated session through the first channel. 

10 

The method may comprise arranging the providing of said second set of 
announcements after the providing of said first set of announcements. 

The method may comprise arranging the providing of said first set of 
15 announcements and the providing of said third set of announcements at 
substantially during an overlapping or same time periods. 

Providing the first set of announcements and providing the second set of 
announcements may comprise transmitting the first set of announcements through 
20 the first channel and transmitting the second set of announcements through the 
second, different channel. 

The method may comprise transmitting the first set of announcements according to 
a session announcement protocol (SAP), unidirectional hypertext transfer protocol 
'5 (UHTTP), asynchronous layered coding (ALC) protocol or similar unidirectional 
protocol based on user datagram protocol (UDP). The method may comprise 
including a description of a corresponding session in each announcement, for 
example arranged according to session description protocol (SDP). 

J The method may comprise providing means for determining whether all of the first 
set of announcements have been provided, for example by providing the first set of 
announcements as a series of linked messages. 
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£ metimd ma r comprise providing ^ fcst sct of ^ , ^ 

time slo«s and providing ^ sec<md set of ta a secon(j 

lots, each ^ of ^ fiKt sM rf Ws1ok b=ing ^ ^ <HflfeMt 

ta.-***,^^,.,,^ The me«hod mav comprise 
/ mutapleimg th e fe, and second seta of announcements. 

According to a second aspect of the presen. invention there is provided a c„mpu.er 
program wh,ch. when executed bv da, pressing appatatoa, canses toe datt 
processmg apparams to perform a method of annonncing sessions transmits 
10 through a network. 

According to a third aspect of the present invention there is provided a method of 
aeeesstng sessions transmitted through a network, the method comprising 
se.eet.velv receiving a firs, set of annonneements describing a pmraHtt of sessions; 
an select receiving a second set of announcements describing , t ,.as t one 
updated session. 

The method mav further comprise determining whether all of said first se« of 
announcements have been received. The method mav further comprise selecting 
no, ,o recerve further said firs. se. of announcements and selecting to receive Jd 
second se, of announcement. The memod ma 7 former comprise selecting no. .„ 
recede a durd set of announcements describing another plurality of sessions 
mcludmg said a. least one upda.ed session. The method mav further comprise 
sefecong to receive a fourth set of announcement, describing a. leas, one mrther 
» updated session. 

According ,o a four* aspec. of me preaen, invention mere is provided a memod of 
~g aesamns ttansmitted mrough a networh, me memod comprising listening 

t -^ s «°f-ouncemen. s deactihmgaplurah V o, s ession S ,de.erminm g 
whemer said fira. se. of announcement have been received; if said firs. se. of 
announcements have been received, men a.opping hs.ening .o said first se. of 
announcement and hs.ening ,o a second se, of announcements describing a, leas, 
one updated session. S 
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The method may further comprise stopping listening to a third set of 
announcements describing a further plurality of sessions including said at least one 
updated session. 

5 

According to a fifth aspect of the present invention there is provided apparatus for 
announcing sessions transmitted through a network, the apparatus comprising 
means for providing a first set of announcements describing a plurality of sessions 
and means for providing a second set of announcements describing at least one 
10 updated session. «• 

According to a sixth aspect of the present invention there is provided apparatus for 
performing the method. 

15 According to a seventh aspect of the present invention there is provided apparatus 
for announcing sessions transmitted through a network, the apparatus comprising a 
first transmitter for providing a first set of announcements describing a plurality of 
sessions and a second transmitter for providing a second set of announcements 
describing at least one updated session, 

20 

The apparatus may comprise means for managing an electronic service guide for 
announcing sessions to be transmitted through the network, means for managing 
content of sessions to be transmitted through the network, means for storing and 
electronic service guide for announcing sessions to be transmitted through the 

25 network, means for storing content of sessions to be transmitted through the 

network, means for determining changes to an electronic service guide, the changes 
corresponding to updated sessions to be transmitted through the network, a server 
for providing information relating to changes to an electronic service guide, the 
changes corresponding to updated sessions to be transmitted through the network, a 

30 server for providing content and/or means for' transmitting data. 

According to an eighth aspect of the present invention there is provided apparatus 
for accessing sessions transmitted through a network, the apparatus comprising 



means for selectively receiving a first set of announcements describing a plurality of 
sessions and means for selectively receiving a second set of announcements 
describing at least one updated session. 

The apparatus may comprise means for determining whether said first set of 
announcements has been received the apparatus being configured such that if the 
determining means determines that the first set of announcements has been 
received, then the means for selectively receiving said second set of announcements 
is configured to receive the second set of announcements. 

The apparatus may comprise means for selectively receiving a third set of 
announcements describing another plurality of session including the at least one 
updated session, the apparatus being configured such that if said determining means 
determines that the first set of announcements has been received, then the means 
for selectively receiving the third set of announcements is configured not to receive 
or not to forward the third set of announcements 

The apparatus may comprise means for receiving data, means for filtering an 
electronic service guide for announcing sessions to be transmitted through the 
network, means for storing an electronic service guide for announcing sessions to 
be transmitted through the network, means for browsing an electronic service guide 
for announcing sessions to be transmitted through the network, means for filtering 
content, means for storing content and/or means for browsing content. 

The apparatus may be a mobile communications device. 

According to a ninth aspect of the present invention there is provided a system for 
presenting program schedule data on a display, said system comprising at least two 
announcements, the schedule data being organized at least partly from a first set of 
announcements describing at least partly a plurality of sessions and at least partly 
from a second set of announcements describing at least one at least partly updated 
session. 
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According to an tenth aspect of the present invention there is provided a system for 
presenting program schedule data on a display, said system comprising at least two 
announcements, the schedule data being organized at least partly from a first set of 
repeatable announcements describing a plurality of sessions, at least partly from a 
5 second set of repeatable announcements describing at least one at least partly 

updated session and at least session descriptions of at least one of the repeatable 
announcements for defining whether the at least one of the first and second 
announcements is received or not. 

10 According to a eleventh aspect of the present invention there is provided a system 
for delivering program schedule data to end-user terminals, said system comprising 
two sets of announcements, each set comprising at least one announcement, the 
schedule data being organized at least partly from a first set of announcements 
describing at least partly a plurality of sessions and at least partly from a second set 

15 of announcements describing at least one at least partly updated session. 

According to a twelfth aspect of the present invention there is provided a system 
for presenting program schedule data to end-user terminals, said system comprising 
at least two set of announcements, each set comprising at least one announcement, 

20 the schedule data being organized at least partly from a first set of repeatable 

announcements describing a plurality of sessions, at least partly from a second set 
of repeatable announcements describing at least one at least partly updated session 
and at least session descriptions of at least one of the repeatable announcements for 
defining whether the at least one of the first and second announcements is received 

25 or not. 

The second set of announcements may include a version number of each updated 
session for allowing a client to detect if they have missed an earlier update. If a 
client detects it has missed an earlier update and is not currently receiving the first 
30 set of announcements, the client may start receiving the first set of announcements 
until it has received a full and latest version of the program schedule data. If the 
client detects that it has received a full and latest version of the program schedule 
data, it may stop receiving the first set of announcements and continues receiving 



- 9 - 



only the second s.« of announce,, cIieat detecB „ has ^ ^ 

update, « may fetch . M Md ktest Teisjon of piogijm ^ r ^ 

^ netWOlfc ^ S « ° f **— «* — ™ may be divided into 
segmenta before transmission Md . of ^ ^ ^ ^ 

' te McaMd » » field of each respective segment- the 

tndrcated location m a 7 enable client, ,o determme whether they have received aU 

segments that constitute a given set or *u j 

given set or whether they need to wait for receiving more 
segments. & 

'0 The program schedule data may be viewed either direcdy by a human end-uaer or 
automatrcally used by a software application. The program schedule data may be 
presented progressively t o a human end-user or made progressively available to an 
automata software application as the aaid data is being received. The program 
scheduie data may be viewed by a human end-user via a graphical user interface. 
The program schedule data may be used by a personal video recorder. 

Embodiment of the present invention win now be described by way of example 
with reference to the accompanying drawings in which: 
Figure 1 is a schematic diagram of a multicasting system 1; 

Figure 2 shows conrent stored in a content darabase; 
Figure 3 shows a Session directory; 

d^rTse* 0 " 8 efeCtt ° niC SC " iCe ^ StOI ' d " " deCtt0niC «""• ■ 

Figure 5 shows updated content stored in a content database; 
Figure 6 shows an updated session directory; 

Figure 7 shows updated electronic service guide data stored in an in an electronic 
service gmde database; 

Figure 8 shows a first example of an improved session directory before an update- 
Ftgure 9 shows the session directory shown in Figme 8 after the update; 
Ftgure 10 shows electronic service gmde data before an update- 
Figure 11 shows electronic service guide data after an update; ' ' 
Figm. 12 shows a session announcement message using SAPand SDP protocols- 
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Figure 13 illustrates transmission of a description of an improved session directory 
using session announcement messages shown in Figure 12; 

Figure 14 is a process flow of a method of operating a datacast service system; 

Figure 15 is a process flow of a method of operating a datacast client; 

Figure 16 shows a second example of an improved session directory after an update 

Figure 17 shows splitting electronic service guide data into data segments; 

Figure 18 another session announcement message using UDP and UHTTP 

protocols; 

Figure 19 illustrates transmission of a description of an improved session directory 
using session announcement messages shown in Figure 18; 

Figure 20 shows transmission of a description of an improved session directory 
using session announcement messages using time division multiplexing; 
Figure 21 shows a schematic diagram of a terminal used to receive multicast data 
and 

Figure 22 shows an electronic service guide browser. 
Multicasting system 1 

Referring to Figure 1, a multicasting system 1 is shown. In this example, the 
multicasting system 1 is an internet protocol *(IP) datacast system. The multicasting 
system 1 includes a datacast service system 2, a datacaster 3, a datacast network 4 
and a plurality of clients 5. For clarity, only one client 5 is shown. 

An administrator 6 provides content, such as audio, video and/or other types of 
data, for datacasting to "clients 5 and provides metadata for describing the content. 
The metadata includes information regarding transmission of content. 

The datacast service system 2 generates IP streams carrying content items and 
related metadata for datacasting to clients 5. The datacaster 3 receives IP streams 
from the datacast service system 2, provides Layer 2 encapsulation and modulation 
and transmits the IP data to clients 5 over the datacast network 4. The datacast 
network 4 is a point-to-multipoint network for delivering IP-based data. Typically, 
the datacast network 4 supports a plurality of simultaneous datacasts to clients 5. In 
this example, the datacast network 4 does not provide a return data path from the 
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client 5 to the datacaster 3. The datacast network 5 may be for example a Digital 
Video Broadcasting (DVB) network, a Digital Audio. Broadcasting (DAB) network, 
an Advanced Television Systems Committee (ATSC) network, an Integrated 
Services Digital Broadcasting (ISDB) network or a Wireless Local Area Network 
(WLAN). The client 5 comprises a terminal for receiving content and content 
descriptions over the datacast network 4 and presenting them to an end-user 7. The 
terminal may be fixed, such as a desk-top personal computer or a television set-top 
box, or portable, for instance a lap-top or notebook personal computer, personal 
digital assistant or mobile telephone handset. 

The datacast service system 2 includes an electronic service guide (ESG) 
management module 8, a content management module 9, an ESG database 10 for 
storing metadata for the electronic service guide, a contents database 11 for storing 
content for datacasting, a service discovery server 12 and a content server 13. 

The ESG management module 8 allows the administrator 6 to control metadata for 
describing datacast content. Content items can be grouped into IP services and IP 
sessions. Content items can be allocated (or de-allocated) time slots for 
transmission. Thus, the metadata describes the structure of content items as a 
hierarchy of IP services and IP sessions. The metadata may also include 
information on the transmission schedule of IP sessions and individual content 
items within IP sessions. 



The content management module 11 allows the administrator 6 to add, replace and 
25 delete content items in the content database 12. 

The service discovery server 10 generates announcements of IP services and IP 
sessions based on the metadata found in the ESG database 9. The announcements 
are sent to the datacaster 3 for transmission over the datacast network 4. 



15 



20 



30 



As will be explained in more detail later, two kinds of announcements are generated. 
A first kind of announcement describes a full IP service directory and a second kind 
of announcement describes updates to the IP service directory. 
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The content server 13 retrieves scheduling information from the ESG database 9 
and, based on the scheduling information, retrieves content from the content 
database 11 and sends it to the datacaster 3 for transmission over the datacast 
5 network 4. 

The client 5 includes a datacast receiver 14, a service discovery client 15, an ESG 
database 16 for storing metadata for the electronic service guide, an ESG browser 
17, a content filtering application 18, a content database 19 and a content browser 
10 20. 

The datacast receiver 14 receives data over the datacast network 4 whereupon it 
demodulates and decapsulates the data. In this case, the datacast receiver 14 
forwards the demodulated and decapsulated data to an IP stack (not shown). The 
15 demodulated and decapsulated data comprises IP packets carrying content streams 
or metadata describing content. The IP packets are forwarded from the stack (not 
shown) to IP-based applications 15, 18 running on the client 5. 

The service discovery client 15 receives the IP packets on one or more given 
20 addresses and one or more given ports for carrying IP service announcements. As 
will be explained in more detail later, the service discovery client 15 can receive 
announcements of the first type describing the full service directory and, either 
alternatively or additionally, announcements of the second type describing updates 
to service directory. The IP packets carry metadata which can be stored in the ESG 
25 database 16 or forwarded directly to the ESG browser 17. 

The ESG database 16 has an information structure very similar to the server-side 
ESG database 9. The ESG database 16 is initially empty, for example when the 
.client 5 is first switched on, but fills up and is updated as IP session announcements 
30 are received from the datacast service system 2. 



The ESG browser 17 allows the end-user 7 to view schedules and descriptions of IP 
services, sessions and content items available from the datacaster service system 2. 
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The ESG browser 17 can retrieve metadata from the ESG database 16 or receive 
metadata directly from the service discovery client 15. 

The content filtering application 18 receives the IP packets on one or more given 
5 addresses and one or more given ports configured by the content browser 20 or 

other applications running on the client. The IP packets carry content which can be 
stored in the content database 19 or forwarded directly to the content browser 20. 

The content browser 20 is loaded and run when the end-user 7 has selected a 
10 particular datacast content item for consumption. The content item can be received 
in real time or retrieved from the content database 19. The content browser 20 can 
be for example a Web browser, an MP3 player or a streaming video client. 

The multicasting system 1 may allow automatic content uploading by external 
15 content providers (not shown) and forwarding of Internet-based content. The 

datacaster 3 can also deliver content to a plurality of datacast networks (not shown), 
each datacast network comprising one or more transponders. 

Sessions 

20 Referring to Figure 2, content 21 is shown which is stored in the content database 
11 and which includes first, second, third and fourth sessions 22„ 22 2 , 22 3 , 23 4 . The 
first, second and third sessions 22,, 22 2 , 22 3 comprise data relating to soccer. For 
example, the first session 22, may include text relating a game, the second session 
22 2 include video streaming and the third session may include audio streaming 22 3 . 

25 The fourth session 22 4 comprises data relating to hockey. A session 22„ 22 2 , 22 3 , 
23 4 may comprise a single IP stream or a plurality of IP streams. 

Session Directory 

Referring to Figure 3, a session directory 23 is shown according to which the 
30 sessions 22 l9 22 2> 22 3 , 22 4 are organised. The session directory 23 includes, at a first 
level, categories such as sports 24,. Further examples of categories include, arts, 
business, computers, games, news and shopping and other categories which are 
commonly found on web portal sites. Each category includes, at a second level, 



- 14- 



sub-categories, such as soccer 25, and hockey 25 2 . Each sub-category may be 
further sub-divided. For instance, the soccer sub-category 25, can be divided into 
soccer leagues, each of which may be divided into league divisions and each of 
which in turn may be divided into players. 

Each category, sub-category or further sub-category may include one or more 
sessions. For example, the soccer sub-category 25, includes the first, second and 
third sessions 22„ 22 2 , 22 3 , while the hockey sub-category category 25 2 includes the 
fourth session 22 4 . 

Referring to Figure 4, ESG data 26 is shown which is stored in the ESG database 9. 
The electronic service guide data 26 includes first, second, third and fourth sets of 
metadata 27„ 27^ 27 3 , 27 4 for describing the first, second, third and fourth sessions 
22„ 22 2 , 22 3 , 22 4 respectively. The ESG data 26 reflects the structure of the session 
directory 22. 

The ESG data 26 is transmitted to clients 5 so as to provide an ESG for users. 
However, there is a problem if the ESG data 26 needs to be updated, as will now be 
explained: 

Referring to Figures 1, 2, 3 and 4, initially, ESG data 26 is transmitted from the 
datacast service system 2 to the client 5. The datacast service system 2 sends sets of 
metadata 27„ 27 2 , 27 3 , 27 4 to the datacaster 3 to be transmitted to clients 5. The 
client 5 begins to receive the sets of metadata 27,, 27 2 , 27 3 , 27 4 and starts to fill the 
initially empty ESG database 16. Eventually, all the sets of metadata 27„ 27 2 , 27 3 , 
27 4 are received and are stored in the ESG database 16. At this point, the ESG is 
complete. 

Referring to Figure 5, the content database 12 is updated and corresponding 
updated content 21' is shown. The updated content 21' includes an updated session 
21,' and a new session 21 s . For example, the first session 21, may be updated by 
replacing a match preview with a match report. The new session 21 s may be a text 
file with a hockey fixture list. 
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Referring to Figure 6, an updated' session directory 23' is shown and includes the 
updated session 21,' and the new session 21 5 . 

Referring to Figure 7, an updated ESG data 26' is shown including an updated first 
sets of metadata 27,, and a new set of metadata 27 s . 

Referring to Figures 1,4,6 and 7, the updated ESG data 26' is transmitted from the 
datacast service system 2 to .the client 5. The datacast service system 2 sends the 
updated ESG data 26' to the datacaster 3 for transmission. The client 5 then 
receives updated sets of metadata 27,', 27 2 , 27 3 , 27 4 , 27 s . However, the client 5 does 
not know whether each set of metadata 27,', 27 2 , 27 3 , 27 4 , 27 5 relates to existing or 
updated sessions. Thus, each incoming set of metadata 27,', 27 2 , 27 3 , 27 4 , 27 5 is 
compared with stored sets of metadata 27„ 27 2 , 27 3 , 27 4 to check whether they 
relate to an updated data session. Processing metadata in this way is wasteful. 
Furthermore, there can be delay between the first session 21, being updated and the 
electronic service guide at the client 5 being revised. 

Therefore, it is desirable to provide an improved session directory and an improved 
ESG. 

One solution to the problem is to split the session directory and divide transmission 
of the ESG accordingly. Description of the session directory is transmitted by 
sending two types of session announcements one for describing the full session 
directory and another for describing an updated session directory, as will now be 
described in more detail: 

Sp Jit Session Directory — First "Example 

Referring to Figures 8 and 9, a first example of an improved session directory 28, 
28' is shown before and after an update respectively. 



The session directory 28, 28' is split into two parts at a relatively high level, in this 
example above the category level, and the two parts are referred to as the full 
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session directory 29, and the updated session directory 29 2 respectively. Later, h 
second example, a session directory is described which is split at a relatively low 
level. 



10 



15 



The full session directory 29, includes substantially the same categories described 
earlier, such as sports 24,. Each category includes sub -categories, such as soccer 25, 
and hockey 25 2 . Similarly, there may be further sub-categories. Each category, sub- 
category or any further sub-category may include one or more sessions. In this 
case, the soccer sub-category 25, includes the first, second and third sessions 22„ 
22^ 22 3 and the hockey sub-category category 25 2 includes the fourth sessions 22 4 . 

The updated session directory 29 2 also includes categories which correspond to the 
categories in the full session directory, such as sports 30,. Similarly, each 
corresponding category includes corresponding sub-categories, such as soccer 31, 
and hockey 31 2 . Similarly, there may be corresponding further sub-categories. Each 
corresponding category, corresponding sub-category or any corresponding further 
sub-category may include, if there has been an update, one or more updated 
sessions. 



20 Before the update, the updated session directory 29 2 does not list any sessions. 

After the update, the updated directory 29 2 lists updated sessions. In this case, the 
soccer sub-category 31, includes the updated, first session 22,' and the hockey sub- 
category category 31 2 includes the fifth session 22 5 . 

25 

This c.onfiguration is used to send two types of session announcements. One type 
of announcement is used to describe all sessions. Another type of announcement is 
used to describe updated sessions. 

30 Thus, the client may listen initially to announcements of the fist type so as to 
receive a description of all the sessions, i.e. the full session directory. Once the 
client has received the description of all sessions, the client may listen only to 
announcements of the second type so as to learn of any updates to the sessions. 
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S ession Announcements using SAP and SDP 

Referring to Figures 10 and 11, a first example of improved ESG data 32, 32' is 
shown before and after the update. 

The improved ESG data 32 includes first, second, third and fourth sets of metadata 
33,, 33 2 , 33 3 , 33 4 for describing the first, second, third and fourth sessions 22„ 22 2 , 
22 3 , 22 4 respectively. 

The updated, improved ESG 32' includes the updated first, second, third, fourth 
and fifth sets of metadata 33,', 33 2 , 33 3 , 33 4 , 33 5 for describing the updated first, 
second, third, fourth and fifth sessions 22,', 22 2 , 22 3 , 22 4 , 22 5 respectively. 

A Session Announcement Protocol (SAP) is used to transmit sets of metadata 33, , 
33,', 33a, 33 3 , 33 4 , 33 5 to clients 5 and a Session Description Protocol (SDP) is used 
to describe the sessions 21 „ 22,', 22 2 , 22 3 , 22 4 , 22 s . Reference is made to "Session 
Announcement Protocol" by M. P. Maher, C. Perkins & E. Whelan, RFC 2974, 
IETF, October 2000 and to "Session Description Protocol" by M. Handley & V. 
Jacobson, RFC 2327, IETF, April 1998. 

The use of the Session Announcement Protocol and the Session Description 
Protocol advantageously permits information describing the structure of session 
directories to be transmitted to clients 5. Reference is made to "Describing session 
directories in SDP" by R. Finlayson, Internet Draft, IETF, January 2001 and 
"Towards multicast session directory services" by A. Santos, J. Macedo & V. Freitas. 

Referring to Figure 12, a session announcement 34 is shown. The session 
announcement 34 comprises an SAP header 35 and payload in the form of an SDP 
description 36 of a session. The SDP description 36 includes a set of metadata 33 
for describing a session. 

Referring to Figure 13, a description of the session directory 28 is transmitted by ' 
sending two types of session announcements 37„ 37 2 each describing a session 
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directory, in this case the full session directory 29, and the updated session directory 
29 2 respectively. 

The first type of session announcements is used to send descriptions of all 
5 sessions, i.e. the fall session directory 29 r During an earlier cycle 38„ the 

announcements 34,, 34 2 , 34 3 , 34 4 describe all sessions 22„22 2 , 22 3 , 22 4 before the 
update and, during a later cycle 38 2 , the announcements 34/, 34 2 , 34 3 , 34 4 , 34 5 
describe all sessions 22/,22 2 , 22 3 , 22 4 , 22 5 after the update. 

The second type of announcements 37 2 is used only to send descriptions of sessions 
that have been added, removed or changed since the transmission of 
announcements. 34„ 34 2 , 34 3 , 34 4 during the earlier cycle 38,. In this example,, no 
cycle precedes the earlier cycle 38,. Thus, during the earlier cycle 38,, there are no 
announcements of the second type 37 2 . During the later cycle 38„ the 
announcements 34/, 34 s describe updated sessions 22/, 22 5 (Figure 9). 

Usually, there will be more than two cycles 38,, 38 2 of announcements. 
Furthermore, more sessions may be updated. Thus, each subsequent cycle (not 
shown) may or may not include announcements of the second type 37 2 . Optionally, 
announcements of the second type 37 2 may be sent repeatedly during a cycle to 
protect against irrecoverable transmission errors. 

Preferably, the structure of the session directory 28 (Figure 9) is described using a 
hierarchy of multicast IP addresses using SDP and SAP. 

A process of describing the structure of the session directory 28 includes 
transmitting a first session announcement on a given multicast address. The first 
session announcement includes a second multicast address and other details relating 
to a session directory. The process includes transmitting a second session 
announcement on the second multicast address. The second session announcement 
includes a third multicast address and other details relating to a session sub- 
directory. Because sub-directories in turn can be used to announce a succeeding 
level of a session directory, the session directory hierarchy can be organized as a 
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tree of any depth. In this example, a root or default session announcement (not 
shown) is transmitted on a widely known address, which specifies a pair of 
addresses for receiving announcements of the first and second types 37j, 37 2 
respectively. 

One or more "category" fields may be included in the session announcements for 
allowing clients 5 to filter and organize session announcements. 

As described earlier, announcements of the first type 37 t are transmitted on a first 
IP address, such as 224.2.17.0.- 

Referring to Figure 13, the first session announcement 34, may include an SDP 
description 36 of the first session 22, including, for example: 

v=0 

o=jsmith 2890842807 2890844525 IN IP4 10.47.16.5 
C=IN 1P4 224.2.17.12/127 
t~2892054126 2892399688 
msdata 9 875 lETHTTP UDP 
a=cat:Pull .Sports . Soccer 

If the first session announcement 34, is updated, then the updated first session 
announcement 34/ map include an SDP description 36 of the updated first session 
22/ including, for example: 

v=0 

o=jsmith 2890842807 2890844526 IN IP4 10.47.16.5 
c=IN IP4 224.2.17.12/127 
t=2892054126 2892399726 
m=data 9 875 TJHTTP TOP 
a=cat .-Full . Sports . Soccer 

Likewise, the second session announcement 34 2 may include an SDP description 36 
of the second session 22 2 including, for example: 
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v=0 

o=jsmith 2890842807 2890844526 I IT IP4 10.47.16:5 
c=Itf IP4 224.2.17.13/127 
t=2892054126 2892399726 
5 m=video 9875 RTP/AVP 31 
a=cat:Pull . Sports . Soccer 

Announcements of the second type 37 2 ate transmitted on a second IP address, 
such as 224.2.17.1. 

10 

Referring still to Figure 13, the updated first session announcement 34/ may include 
an SDP description 36 of the updated first session 22/ (Figure 9) including for 
example: 

15 v=0 

o=jsmith 2890842807 2890844526 IN IP4 10.47.16.5 
c=riT IP4 224.2.17.12/127 
t=2892054126 2892399726 
m=data 9 87 5 XJHTTP TOP 
20 a=cat: Update . Sports . Soccer 

The updated session 22/ (Figure 9) may be identified as an updated session in a 
number of ways: 

25 Firstly, the first session announcement 34 1 and the updated first session 

announcement 34/ specify different version numbers in the "o=" field, namely 
2890844525 and 2890844526 respectively. Thus, identifying an updated session 
may include comparing version numbers of the first and updated first session 
announcements 34 t , 34/ and noting different version numbers. 

Secondly, the updated first session announcement 34/ is provided through a 
different channel, in this case a different IP address, which is reserved for 
announcements relating to updated sessions. Thus, identifying an updated session 
may include receiving an announcement on a different channel. 
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Thirdly, the updated first session announcement 34,' includes a category field, 
which identifies the fact that the session announcement relates to an update. Thus, 
identifying an updated session may include, determining whether an announcement 
identifies itself as relating to an update and/or determining a position within a 
session directory. 

Method of operating the datacast service system 2 

Referring to Figures 1 and 14, a method of operating the datacast service system 2 is 
shown. 

The ESG management module 8 identifies whether sessions have been updated in 
the content database 12 (step SI), If it identifies any updated sessions, then it 
updates corresponding sets of metadata in the ESG database (step S2). Updating, 
may include adding or deleting metadata. Metadata is passed to the service 
discovery server 10, which generates updated session announcements for any 
updated sets of metadata (step S3). The service discovery server 10 forwards a first 
set of announcements describing a plurality of sessions, in other words fall session 
announcements, and a second set of announcements describing at least one updated 
session, in other words updated session announcements, to the datacaster 3 through 
different channels, such as different IP addresses (steps S4 & S5). The datacaster 3 
receives the announcements and transmits them over the datacast network 4 to each 
clients 5. 



Method of operating client 5 
• Referring to Figures 1 and 15, a method of operating the client 5 is shown. 

The client 5 checks whether it has received all the session announcements of the 
first type 37, (step Tl). If not, the client 5 listens to both types of announcements 
37„ 37 2 (step T1& T2). However, if the client 5 has received all the session 
announcements of the first type 37„ then it can stop listening to announcements of 
the first type 37, and continue listening only to announcements of the second type 
37 2 . This has the advantage that it saves processing power and electrical power 
. because fewer session announcements are received and/or processed. . 
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The first and second types of announcements 37,, 37 2 may include multicast 
addresses of announcements relating to other session directories, which in turn may 
include multicast addresses of announcements relating to farther session directories. 

Announcements of the first type 37, may be considered as relating to a session 
directory including sub-directories to a given depth of directory hierarchy. 
Announcements of the second type 37 2 may likewise be considered as relating to a 
session directory including sub-directories to a given depth of directory hierarchy. 
If announcements of either type 37„ 37 2 relate to more than one session directory, 
then they can be used to announce the details of a different sub-tree of the IP 
session hierarchy. Thus, if descriptions of multiple subdirectories are transmitted 
using announcements of the first type 37„ then the client 5 may stop receiving 
announcements relating to a particular subdirectory as soon as it has received all the 
different session descriptions of that subdirectory. 

Split Session Directory — Second Example 

Referring to Figure 16, a second example of an improved session directory 28" is 
shown. The session directory 28" is split into two parts at a relatively low level, in 
this example above the session level, and the two parts are referred to as the full 
session directory 29 la , 29 lb and the updated session directory 29^, 29 2b respectively. 

The ESG data 32 and the updated ESG data 32' are modified to reflect the structure 
of the second example of an improved session directory 28". 

Session Announcements using UHTTP 

A drawback of using session announcements employing SAP and SDP is that it is 
difficult for a client 5 to establish when it has received enough announcements of 
the first type 37, to describe the full session directory 29,. Announcements 34, 
34 2 , 34 3 , 34 4 , 34 5 may be lost or corrupted and these protocols do not allow such 
events to be detected. 
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In an alternariveernbodintent, ^ ^ . ^ ^ 
aanouncameots describing the ftffl sessioil 

A Unidireeriona. Hypertext Transfer Protocol (UHTTP) i s used to imp.emenr a 
concatenated transfer of n,u,rip.e session descriptions and references are tnade to 
the Soctery of Morion Picture and Television Engineers standard SMPTE 364M- 
200 D«, Dam EssMce ... Uniditect;onal Hm ( 

and t„ A ^ C: Tbe Unidireeriona, Hypertext Transfer Protocol (UHTTP)" in 
^ Enhanced Content Specification, Advanced TeleWsion Ennancenren. Pornnt. 

rj^rZT MIME ~W protocol, so lowing a ' 

stngle UHTTP transfer ,o comprise n,u>uple independent MIME objects and 
reference ts n,.de to "Tie MIME Multipart/Related Content-type" bv E Levi 
RFC 2387, IETF (1998). P by E. Levinson, 

5 

Keferring . Fign, 17 , ^ ESG data 3 2 is consideIed „ . 

an be spht tnto a p.urafity o, data segments 40„ 40,, 40,. In tbis e,ansp,e, tbere are 
fewer data segntents d,an tbere are sets of metadata. However, rite numbe of LT 
stents may be e,ua, or greater tban tbe number of seta of metadata. Kednn^ 
e^or correcnon segments (no, shown) may be c,leu>a t ed and interleaved witn tbe 
dat, segments 40„ 40„ 4 0j . Tbe updated electronic service guide data 32- is 
processed in the same way. 

Referring ,o F*ure 18, . user datagram protocol (U D P) packet 41 is shown whicb 

UHTTP packet 44 wbtch includes a UHTTP beader 45 and a data segmen. 40, 40 
40, as payload. UHTTP allows each data segment 40„ 40, 40, to benumbed 

eSZ r2. Pig T e M " — * " * **- — ^ updated 

M ' 8 3180 ~" ed » » transfers. For the ESG data 32 Lt 

second and third UDP Dacket* 41 a-, a*' ' 

a , ^ u * 413 " e Likewise, for the 

updated ESG 32', fourth, fifth and sixth UDP packets 41 41 4l \ , 
T« u -r t""-&.e.zs <u 4y 41 5 , 41 6 ate transmitted. 

In each case, if one or more UDP packet 41, 41 41 41 41 41 ■ 

f <n 2 , 41 3 , 41 4 , 41 s , 41 6 is unsuccessfully 
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transmitted or data segment contained therein is unsuccessfully retrieved, then 
corresponding UDP packets 41 u 41* 41 3 , 41 4 , 41 5 , 41 6 are re-transmitted. 

Descriptions of updated sessions are transmitted in a seventh UDP packet 41 7 . 

As described earlier, a default session announcement may be used to provide details 
of the full and updated session directories 29 „ 29 2 . An example of a default session 
announcement may include: 

v=0 

o=dcaster 4289098098 4289099125 IN IP4 130.230. 3. 2 
s=Experimental session directory service 

i=Full and update session directories delivered via UHTTP 

us:http z //www. datacas ter . com 

e=dcaster@da tacaster.com 

csIM IP4 224.2.17.12/127 

t=2 873 3 9749 6 2 87 3404696 

ms=data 42451 udp uhttp 

a=X- session- directory- full 

madata 42452 udp uhttp 

a=X- session -directory-updates 

In this example described, the full session announcements and updated session 
announcements are provided on different port numbers. Also in this example, 
UHTTP is used full session announcements and updated session announcements. 
However, UHTTP may be used for full session announcements, while SAP and SDP 
may still be used for updated session announcements. 

Numbering of data segments 40„ 40 2 , 40 3 allows the client 5 to detect when they 
have received the ESG data 32. Once this occurs, the client 5 listens for updates. 

The use of UHTTP has another advantage. It supports forward error correction 
(FEC) which can be used to increase the probability of successful transmission even 
if bit and burst errors occur in transmission. If, however, FEC fails to* recover any 
errors at the client-end, the client 5 waits for periodic UHTTP retransmission. 
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Alternatively, if a return path is provided, then automatic repeat request (ARQ) may 
be used. 



Other protocols, such as Asynchronous Layer Coding, which provide reliable 
delivery, of content may be used. 

Asynchronous Layer Coding (ALC) is a scalable reliable content delivery protocol 
for IP multicasting and reference is made to "Asynchronous Layer Coding protocol 
instantiation" by M. Luby, J. Gemm^U, L. Vicisano, L. Rizzo and J. Crowcroft, 
IETF, April 2002. 

Reference is also made to "Reliable Multicast Transport Building Blocks for One- 
to-Many Bulk-Data Transfer" by B. Whetten, L. Vicisano, R. Kermode, M. Handley, 
S. Floyd and M. Luby, RFC 3048, IETF, January 2001. 

Reference is also made to "Layered Coding Transport building block" by B. 
Whetten, L. Vicisano, L. Rizzo, M. Handley, S. Floyd and M. Luby, Internet Draft, 
IETF, February 2002. 

Time Division Multiplexing 

In the embodiments described earlier, IP packets comprising portions of ESG data 
32, 32' can be transmitted by the datacaster 3 to the client 5 as-and-when 
transmission slots become available. However, to ensure that the client 5 receives 
the IP packets, it is preferable that the client 5 be configured to receive data at any 
time. This has the drawback of unnecessarily using processing and electrical power. 

A solution to this problem is to employ time division multiplexing (TDM). 

Referring to Figure 20,- an alternative manner of transmitting a description of the 
session directory 28 is shown. In this example, only a later cycle 38 2 * including the 
two types of session announcements 37 t , 37 2 is shown. 
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Announcements of the first type 37, for describing ESG data and announcements 
of the second type 37 2 for describing updates to ESG data are transmitted in 
different time slots 45,, 45 2 . For example, the announcements of the first and 
second types 37 lf 37 2 are transmitted in alternate time slots. However, the time 
slots 45„ 45 2 need not be adjacent. The time slots may be of variable or fixed 
length. 

Thus, if the client 5 wishes to listen for updates to ESG data, then they do not need 
to listen to time slots 45, during which announcements of the first type 37, are 
transmitted, but may listen to time slots 45 2 during which only announcements of 
the second type 37 2 are sent. This allows the client 5 to switch off its receiver 14 
(Figure 1) during time slots 45,. 

"Datacast client 5 

Referring to Figure 21, the datacast client 5 comprises a processor 46, input/output 
interface 47, memory 48, a receiver 49 and a transceiver 50 which are connected via 
a bus 51. The input/ output interface 47 is connected to a user interface 52, a 
display 53, storage 54 and speaker 55. 

The datacast client 5 may be a mobile communication device for use with first and 
second wireless communication networks. For example, the first wireless 
communication network may be a DVB-T or DAB network and the receiver 49 may 
be configured to receive and demodulate signals from a DVB-T or DAB network. 
The second wireless communication network may be a UMTS network or other 3G, 
2.5G or 2G telecommunications network and the transceiver .50 may be configured 
to receive/transmit and demodulate /modulate signals via a UMTS or similar 
network. 

The datacast client 5 may be a set-top box connected to a television set for use with 
first and second wired and/or wireless communication networks. For example, the 
first communication network may be a DVB-T network and the receiver 49 may be 
configured to receive and demodulate signals from a DVB-T network. The second 
communications network may the Internet and the transceiver 50 may include a 
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U-g t„o networks, sesslons Md session u 
different networks. Alternative* 4e flIst and second ^ 
,m,>mCtmfflB be transmitted over different networks. 

Computer programs (no, shown) when loadcd toto memory 48 ^ 
processor 46 cause 4 « pr„ 46> to CMjunction ^ other ' 

hold *. ESG and content databases U, 19. The user interface 52 anows the 
user to ptov.de insttuctions to the ESG browser 17 and the content browser 20 
such as msttuction to seiec, a S e ss ion. The displav 53 allows the user to view ' 
»- descriptions and session con«en t The speaker 54 alW the user to heat 
session content. r 



ES G browser 

Referring to FiguIe 22> „ of ^ ^ 

» ™dow 5 mcludes , fits, section 58 tot receiving Prions fot ^ J^. 
for exampfc on riae haris of date of .remission, whether a session is currL hit 
ttansmnted ot search .eras. The window 57 includes a second aection 59 fol 
£p>avmg a hs t of filtered sessions and receiving insttuctions to select a session ' 
ttt wmdow 57 nrdudes a third section 60 for displaving a description of a selected 
« season and receiving instructions to access the session. 

< 

It will be appreciated that manv modifications mav be made to *, embodiment 
hereinbefore described. 

30 Session announcements may be unicast r»*W t u , • 

y oc unicast, rather than multicast, to a client. 
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Sessions and session announcements may be transmitted over different networks. 
For example, sessions may be transmitted over a DVB network and session 
announcements may be sent via a DAB network. 

The first and second types of session announcements may be transmitted over 
different networks. For instance, announcements of the first type may be 
transmitted through a DVB-T network, while announcements of the second type 
may be sent though a 3G network. The first and second types of session 
announcements may be transmitted through the same network, but over different 
physical channels, for example at different carrier frequencies. The first and second 
types of session announcements may be transmitted through the same network and 
over the same physical channels, but over different logical channels. 
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Claims 

1. A method of announcing sessions transmitted through a network, the method 
comprising: 

providing a first set of announcements describing a plurality of sessions; and 
providing a second set of announcements describing at least one updated 
session. 

2. A method according to claim 1, comprising providing said first set of 
announcements through a first channel and providing said second set of 
announcements through a second, different channel. 

3. A method according to claim 1 or 2, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first address and providing said 
second set of announcements through a second, different address respectively. 

4. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first destination address. and 
providing said second set of announcements through a second, different destination 
address respectively. 

5. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first IP address and providing 
said second set of announcements through a second, different IP address 
respectively. 

6. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first IP multicast address and 
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providing said second set of announcements through a second, different IP 
multicast address respectively. 

7. A method according to any preceding claim, wherein providing said first set of 
5 announcements and providing said second set of announcements comprises 

providing said first set of announcements through a first port number and providing 
said second set of announcements through a second, different port number 
respectively. 

10 8. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first logical channel and 
providing said second set of announcements through a second, different logical 
channel respectively. 
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9. A method according any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
including in each announcement of said first set of announcements data for 
identifying said announcement as an announcement which describes a one of said 
plurality of sessions and in each announcement of said second set of 
announcements data for identifying said announcement as an announcement which 
describes a one of said at least one updated session. 

1 0. A method according any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
including in each announcement of said first set of announcements respective data 
for specifying a position of a corresponding session within a first portion of a 
. session directory and including in each announcement of said second set of 
announcements respective data for specifying a position of a corresponding session 
30 within a second portion of the session directory. 

11. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
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providing said first set of announcements through a first physical channel and 
providing said second set of announcements through a second, different physical 
channel respectively. 

12. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
providing said first set of announcements through a first network and providing 
said second set of announcements through a second, different network respectively. 

13. A method according to any preceding claim, further comprising providing a 
third set of announcements describing another plurality of sessions including said at 
least one updated session. 

14. A method according to any preceding claim, comprising: 
providing said first set of announcements through a first channel; 
providing said second set of announcements describing at least one updated 

session through a second, different channel; and 

providing a third set of announcements describing another plurality of 
sessions including said at least one updated session through said first channel. 

15. A method according to any preceding claim, comprising arranging the 
providing of said second set of announcements after the providing of said first set 
of announcements. 

16. A method according to any preceding claim, wherein providing said first set of 
announcements and providing said second set of announcements comprises 
transmitting said first set of announcements through a first channel and 
transmitting said second set of announcements through a second, different channel.' 

17. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to a session announcement protocol (SAP). 
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18. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to a unidirectional transport protocol. 

19. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to unidirectional hypertext transfer protocol 
(UHTTP).- 

20. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to asynchronous layered coding (ALC) protocol. 

21. A method according to any preceding claim, comprising transmitting said first 
set of announcements according to user datagram protocol (UDP). 

22. A method according to any preceding claim, comprising including a 
description of a corresponding session in each announcement. 

23. A method according to any preceding claim, comprising including a 
description of a corresponding session arranged according to session description 
protocol (SDP) in each announcement. 

24. A method according to any preceding claim, comprising providing means for 
determining whether a,ll of said first set of announcements have been provided. 

25. A method according to any preceding claim, comprising providing said first 
set of announcements as a series of linked messages. 

26. A method according to any preceding claim, comprising providing said first 
set of announcements in a first set of time slots and providing said second set of 
announcements in a second set of time slots, each timeslot of said first set of 
timeslots being provided at a different time from each timeslot of said second set of 
timeslots. 
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21 A method according to any preceding ^ _ multiplexing ^ ^ 

and second sets of announcements. 

28. A Hod substafltially ^ heieifibefore d£scribed ^ 
^ to 22 of the accompanying drawings. 

29. A compute, program which, when executed b 7 data processing 
the data DrocpsQino- 



/0 



/5 



-?0 



~u,a through . Mtwort according to any precediag ^ 

30. A method of accessing sessions ttaasmi „ cd a ne 

comprising: ua 

select reiving a first set o'f announcements describing a ptaraIity of 
sessions; and ox- / v^i. 

sel.cri.ely receiving a second se, of announcement, describing at leas, one 
updated session. 



31. A method according to claim 30, further comprising deterrnining whether all 
of sam first set of announcements have been received. 

32. A method according to claim 31, further comprising selecting 



r , ? . , _ * o "-v^ig not to receive 

lutther satd fits, set of announcements and selecting to receive said second set of 
announcements. 



- 33. A method according to Cairn 3! or 32, further comprising selecting no, «o 
-cetve a thtrd se, of announcements describing another plurahty of seals 
meludmg said at least one upaated session. 

34. A method according ,o anyone of claims 31 «o 33, further comprising 

T:TI M reCd7e ' foUI,h S " ° f — - « one furmer 

updated session. 
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35. A method of accessing sessions transmitted through a network, the method 
comprising: 

listening to a first set of announcements describing a plurality of sessions; 
determining whether said first set of announcements have been received; 
if said first set of announcements have been received, then 
stopping listening to said first set of announcements and 
listening to a second set of announcements describing at least one updated 
session. 

36. A method according to claim 35, further comprising: 

stopping listening to a third set of announcements describing a further 
plurality of sessions including said at. least one updated session. 

37. Apparatus for announcing sessions transmitted through a network, the 
apparatus comprising: 

means for providing a first set of announcements describing a plurality of 
sessions; and 

means for providing a second set of announcements describing at least one 
updated session. 

38. Apparatus for performing the method according to any one of claims 1 to 28. 

39. Apparatus for announcing sessions transmitted through a network 
substantially as hereinbefore described with reference to Figures 1 to 22 of the 
accompanying drawings. 

40. Apparatus for announcing sessions transmitted through a network, the 
apparatus comprising: 

-a first transmitter for providing a first set of announcements describing a 
plurality of sessions; and 

a second transmitter for providing a second set of announcements describing 
at least one updated session. 
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41. Apparatus for accessing sessions transmitted through a network, the apparatus 
comprising: 

means for selectively receiving a first set of announcements describing a 
plurality of sessions; and 

means for selectively receiving a second set of announcements describing at 
least one updated session. 

42. Apparatus according to claim 41, comprising:. 

means for determining whether said first set of announcements has been 
received; 

said apparatus being configured such that if said determining means 
determines that said first set of announcements has been received, then the means 
for selectively receiving said second set of announcements is configured to receive 
said second set of announcements. 

43. Apparatus according to claim 42, comprising: 

means for selectively receiving a third set of announcements describing 
another plurality of session including said at least one updated session; 

said apparatus being configured such that if said determining means 
determines that said first set of announcements has been received, then the means 
for selectively receiving said third set of announcements is configured not to receive 
or not to forward said third set of announcements. 

44. Apparatus according to any one of claims 41 to 42 which is a mobile 
communications device. 

45. Apparatus for accessing sessions transmitted through a network substantially 
as hereinbefore described with reference to Figures 1 to 22 of the accompanying 
drawings. 

46. A system for presenting program schedule data on a display, said system 
comprising at least two announcements, the schedule data being organized at least 
partly from a first set of announcements describing at least partly a plurality of 
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sessions and at least partly from a second set of announcements describing at least 
one at least partly updated session. 

47. A system for presenting program schedule data on a display, said system 
5 comprising at least two announcements, the schedule data being organised at least 
partly from a first set of repeatable announcements describing a plurality of 
sessions, at least partly from a second set of repeatable announcements describing at 
least one at least partly updated session and at least session descriptions of at least 
one of the repeatable announcements for defining whether the at least one of the 
10 first and second announcements is received or not. 

48. A system for delivering program schedule data to end-user terminals, said 
system comprising two sets of announcements, each set comprising at least one 
. announcement, the schedule data being organized at least partly from a first set of 
announcements describing at least partly a plurality of sessions and at least pardy 
from a second set of announcements describing at least one at least partly updated 
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session. 



49. A system for presenting program schedule data to end-user terminals, said 
20 system comprising at least two set of announcements, each set comprising at least 
one announcement, the schedule data being organized at least partly from a first set 
of repeatable announcements describing a plurality of sessions, at least partly from a 
second set of repeatable announcements describing at least one at least partly 
updated session and at least session descriptions of at least one of the repeatable 
25 announcements for defining whether the at least one of the first and second ' 
announcements is received or not. 

50. A system according to any one of claims 47 to 49 claim, wherein the second 
set of announcements include a version number of each updated session for 

30 allowing a client to detect if they have missed an earlier update. 

51. A system according to claim 50, wherein if a client detects it has missed an 
earlier update and is not currendy receiving the first set of announcements, the 
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client starts receiving the first set of announcements until it has received a full and 
latest version of the program schedule data. 

52. A system according to ciaim 5 1 , wherein if the client detects that it has 
received a full and latest version of the program schedule data, it stops receiving the 
first set of announcements and continues receiving only the second set of 
announcements. 



53. A system according to any one of claims 50 to 52, wherein if the client detects 
10 it has missed an earlier update, it fetches a full, and latest version of the program 

schedule data over an interactive network. 

54. A system according to any one of claim 47 to 53, where each set of repeatable 
announcements is divided into segments before transmission and a location of each 
segment within a whole transfer is indicated in a framing field of each respective 
segment; the indicated location enables clients to determine whether they have 
received all segments that constitute a given set or whether they need to wait for 
receiving more segments. 
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55. A system according to any one of claims 47 to 54, wherein the program 
schedule data is viewed either directly by a human end-user or automatically used by 
a software application; 

56. A system according to any one of claims 47 to 55, wherein the program 
schedule data is presented progressively to a human end-user or made progressively 
available to an automatic software application as the said data is being received. 

57. A system according to claim 55 or 56, wherein the program schedule data is 
viewed by a human end-user via a graphical user interface. 

58. A system according to claim 55 or 56, wherein the program schedule data is 
used by a personal video recorder. 
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• Abstract 
A method of announcing sessions 

An electronic service guide (ESG) is provided by transmitting announcements 
describing multimedia sessions, such video streams. Sessions are organised into a 
session directory (28) which is split into two parts: a full session directory (29 t ) and 
an updated session directory (29 J.. A first kind of announcement describes all 
sessions in the full session directory. A second kind of announcement describes 
sessions in the updated session directory. Once a client has received a description 
of the full session directory, it need only listen to announcements of the second 
type so as to learn of any updates to sessions. 
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